Web designers use markup languages to create and modify websites. Graphical user interfaces (GUIs), also known as user interface (UI) controls, are desirable for building web applications, as they allow the user to interact with the application in a standard, familiar way. UI controls are high-level constructs with data and function methods underlying a visual front-end. They behave in standard, expected manners-changing their states (e.g., selected, unselected, focussed, disabled, etc.), which usually have different appearances, in response to user interaction. For example, clicking on a push-button will cause the button to go into its down-state in response to the ‘mousedown’ event and back into its up-state in response to the ‘mouseup’ event. Another intrinsic behavior of UI controls is that they trigger the execution of predetermined actions in response to specified events, such as the user clicking on them with the mouse.
Hypertext markup language (HTML) is a commonly used markup language, or platform, with which to build web applications. HTML is limiting, with poor graphics support (only bitmaps, no vectors), its lack of absolute positioning, its small set of user interface (UI) controls and its inability to describe the appearance of those UI controls (the HTML browser decides on the appearance). Scalable vector graphics (SVG) is a language for describing two-dimensional graphics in extensible markup language (XML), which may soon become the platform of choice with which to build web applications. SVG provides an author with a rich set of vector graphics features (as well as bitmaps) and absolute control over their positioning.
SVG-based web applications create their own UI controls using SVG to describe the visual appearance and script to describe the data and function members, which provide the UI controls with the standard intrinsic behaviors discussed previously. This means, however, that non-developers cannot author the UI portion of the content, a fair amount of script for the UI controls must be transferred to the client (a significant problem for wireless devices) and the UI controls may seem to react sluggishly to user input, due to the nature of script being interpreted at run-time as opposed to native code (e.g. C or C++) being interpreted (and optimized) at compile time.
Using scripts to author the UI portion of Web content has limitations. Script requires programming ability. Many Web designers do not have the programming skills required to build UI controls via scripting. Aside from all the internal logic that a UI control requires, one must also know how to manipulate the DOM via the DOM methods so as to give the UI control a visual appearance and interactivity.
Script requires time to develop. Even for developers, creating a suite of robust, responsive UI controls requires a significant amount of script, which takes a significant amount of time to implement.
Script is difficult to auto-generate. One could attempt to assist Web designers by creating pre-canned scripts for the most commonly required functionality. However, supporting the insertion of pre-canned scripts via an integrated development environment (IDE) is both complicated and limiting. Auto-generated script cannot easily be customized afterwards, unless the IDE absolves itself of all responsibility should the designer make modifications.
Software exists that allows one to map input XML markup to output markup, automatically generating extensible stylesheet language transformation XSLT (the most commonly used XML markup language for transforming XML markup to a different form of markup). However, script is difficult to data-map.
Script relies on full DOM support. Scripts are only as powerful as the DOM methods that the viewer supports. Although it is desirable to have all viewers support the entire spectrum of DOM methods, they currently do not. Thus one must write script that only uses the API's supported by all viewers, in order to ensure that the script works on all viewers (i.e., one must program towards the lowest common denominator).
Script is complex. Creating a simple editable textBox control, for instance, could require thousands of lines of code, since SVG 1.1 does not support editable text. One has to intercept keyboard events, modify the data of existing ‘text’ elements, create new ‘text’ or ‘tspan’ elements for every line, support the Backspace and Delete keys, support auto-wrapping, etc. But inserting a simple ‘textBox’ element requires no programming and is only one line of markup.
Script is slower than native code. Scripts are interpreted, and thus provide slower performance than what would be possible with a natively-implemented markup language. Just having a script interpreter is a lot of overhead for a small device.
Script must use DOM interfaces. Scripts can only manipulate the DOM via the DOM methods, which are abstractions on top of the real object model used by the viewer. Natively-implemented markup could access the real object model directly, which may improve performance even more.
Script requires more data to transfer. Scripts greatly add to the amount of data needed to be transferred. This is a problem especially for small devices.
XUL is an XML markup language for UI controls created by the Mozilla group, specifically for use in their Mozilla HTML web browser. While XUL does offer an extensive list of UI controls, offers limited skinnability (control of appearance) and is not tied to a forms creation/processing/submission model, XUL is intended for use in HTML browsers and thus does not allow for absolute positioning nor absolute control of the appearance, cannot be easily hooked up to actions and cannot be easily used for forms. XUL is not supported in some SVG viewers.
XForms is another XML markup language which includes UI controls. XForms was designed for forms, however. XForms only supports UI controls needed for forms, does not allow for absolute control over their positioning and their appearance, cannot be easily hooked up to actions (except those that affect just its own UI controls and its “instance”, or forms, data) and is very tightly tied to its forms model. XForms is not supported in some SVG viewers.